存储进阶—怎么才能保证 IO 数据的安全？
写成功了数据就安全了吗？
思考一个问题：写数据做到什么程度才叫安全了？
就是：用户发过来一个写 IO 请求，只要你给他回复了 “写成功了”，那么无论机器发生掉电，还是重启等等之类的，数据都还能读出来。
所以，在我们不考虑数据静默错误的前提下，数据安全的最本质要求是什么？
划重点：那就是数据一定要在非易失性的存储介质里，你才能给用户回复“写成功”。请一定要记住这句话，做存储开发的人员，80% 的时间都在思考这句话。
那么常见的易失性介质和非易失性介质有哪些呢？
易失性介质：寄存器，内存 等；非易失性介质：磁盘，固态硬盘 等；
从上到下，速度递减，容量递增，价格递减。
Linux IO 简述
我们前面提到一个文件的读写方式，标准库的方式和系统调用的方式。无论是哪一种，本质上都是基于文件的一种形式，下面承接了一层文件系统，主要层次：系统调用 -> vfs -> 文件系统 -> 块设备 -> 硬件驱动 。
我们 open 了这个文件，然后 write 数据进去。好，现在思考一个问题，当 write 返回成功之后，数据到磁盘了吗？
答案是：不确定。
因为有文件系统的 cache ，默认是 write back 的模式，数据写到内存就返回成功了，然后内核根据实际情况（比如定期或者脏数据达到某个阈值），异步刷盘。
这样的好处是保证了写的性能，貌似写的性能非常好（可不好嘛，数据写内存的速度），坏处是存在数据风险。因为用户收到成功的时候，数据可能还在内存，这个时候整机掉电，由于内存是易失性介质，数据就丢了。丢数据 是存储最不能接受的事情，相当于丢失了存储的生命线。
动画演示：
那么，怎么保证数据的可靠？
划重点：还是那句话，一定要确保数据落盘之后，才向用户返回成功。
那么怎么才能保证这一点？有以下 3 种方法。
open文件的时候，用O_DIRECT模式打开，这样write/read的时候，文件系统的 IO 会绕过 cache，直接跟磁盘 IO；open文件的时候，使用O_SYNC模式，确保每一笔 IO 都是同步落盘的。或者write之后，主动调用一把fsync，强制数据落盘；读写文件的另一种方式是通过 mmap函数把文件映射到进程的地址空间，读写进程内存的地址的数据其实是转发到磁盘上去读写，write之后主动调用一把msync强制刷盘；
三种安全的 IO 姿势
DIRECT IO 模式能够保证每次 IO 都直接访问磁盘数据，而不是数据写到内存就向用户返回成功的结果，这样才能确保数据安全。因为内存是易失性的，掉电就丢了，数据只有写到持久化的介质才能安心。
动画演示：
读的时候也是直接读磁盘，而不会缓存到内存中，从而也能节省整机内存的使用。
缺点也同样明显，由于每次 IO 都要落盘，那么性能肯定看起来差(但你要明白，其实这才是真实的磁盘性能)。
划重点：使用了 O_DIRECT 模式之后，必须要用户自己保证对齐规则，否则 IO 会报错，有 3 个需要对齐的规则：
磁盘 IO 的大小必须扇区大小（512字节）对齐 磁盘 IO 偏移按照扇区大小对齐； 内存 buffer 的地址也必须是扇区对齐；
c 语言示例：
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <stdint.h>
extern int errno;
#define align_ptr(p, a) \
(u_char *)(((uintptr_t)(p) + ((uintptr_t)a - 1)) & ~((uintptr_t)a - 1))
int main(int argc, char **argv)
{
char timestamp[8192] = {0,};
char *timestamp_buf = NULL;
int timestamp_len = 0;
ssize_t n = 0;
int fd = -1;
fd = open("./test_directio.txt", O_CREAT | O_RDWR | O_DIRECT, 0644);
assert(fd >= 0);
// 对齐内存地址
timestamp_buf = (char *)(align_ptr(timestamp, 512));
timestamp_len = 512;
n = pwrite(fd, timestamp_buf, timestamp_len, 0);
printf("ret (%ld) errno (%s)\n", n, strerror(errno));
return 0;
}
编译命令：
gcc -ggdb3 -O0 test.c -D_GNU_SOURCE
生成二进制文件，执行下就知道了，这个是成功的。
sh-4.4# ./a.out
ret (512) errno (Success)
如果为了验证对齐导致的错误，读者朋友可以故意让 io 的偏移或者大小，或者内存 buffer 地址不按照 512 对齐（比如故意让 timestamp_buf 对齐之后的地址减 1，再试下运行），会得到如下：
sh-4.4# ./a.out
ret (-1) errno (Invalid argument)
思考问题：有些童鞋可能会好奇问了？IO 大小和偏移按照 512 对齐我会，但是怎么才能保证 malloc 的地址是 512 对齐的呢？
是啊，我们无法用 malloc 来控制生成的地址。这对这个需求，我们有两个解决办法：
方法一：分配大一点的内存，然后在这个大块内存里找到对齐的地址，只需要确保 IO 大小不会超过最后的边界即可；
我上面的 demo 例子就是如此，分配了 8192 的内存块，然后从里面找到 512 对齐的地址。从这个地址开始往后 512 个字节是绝对到不了这个大内存块的边界的。对齐的目的安全达成。
这种方式实现简单且通用，但是比较浪费内存。
方法二：使用 posix 标准封装的接口 posix_memalign 来分配内存，这个接口分配的内存能保证对齐；
如下，分配 1 KiB 的内存 buffer，内存地址按照 512 字节对齐。
ret = posix_memalign (&buf, 512, 1024);
if (ret) {
return -1;
}
思考一个问题：O_DIRECT 模式 的 IO 一般是哪些应用场景？
最常见的是数据库系统，数据库有自己的缓存体系和 IO 优化，无需内核消耗内存再去完成相同的事情，并且可能好心办坏事； 不格式化文件系统，而是直接管理块设备的场景；
sync 功能：强制刷新内核缓冲区到输出磁盘。
在 Linux 的缓存 I/O 机制中，用户和磁盘之间有一层易失性的介质——内核空间的 buffer cache；
读的时候会 cache 一份到内存中以便提高后续的读性能； 写的时候用户数据写到内存 cache 就向用户返回成功，然后异步刷盘，从而提高用户的写性能。
读操作描述如下：
操作系统先看内核的 buffer cache有缓存不？有，那么就直接从缓存中返回；否则从磁盘中读取，然后缓存在操作系统的缓存中；
写操作描述如下：
将数据从用户空间复制到内核的内存 cache 中，这时就向用户返回成功，对用户来说写操作就已经完成； 至于内存的数据什么时候才真正写到磁盘由操作系统策略决定（如果此时机器掉电，那么就会丢失用户数据）； 所以，如果你要保证落盘，必须显式调用了 sync命令，显式把数据刷到磁盘（只有刷到磁盘，机器掉电才不会导致丢数据）；
划重点：sync 机制能保证当前时间点之前的数据全部刷到磁盘。。而关于 sync 的方式大概有两种：
open的使用使用O_SYNC标识；显式调用 fsync之类的系统调用；
方法一：open 使用 O_SYNC 标识；
c 语言示例：
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <stdint.h>
extern int errno;
int main(int argc, char **argv)
{
char buffer[512] = {0,};
ssize_t n = 0;
int fd = -1;
fd = open("./test_sync.txt", O_CREAT | O_RDWR | O_SYNC, 0644);
assert(fd >= 0);
n = pwrite(fd, buffer, 512, 0);
printf("ret (%ld) errno (%s)\n", n, strerror(errno));
return 0;
}
这种方式能保证每一笔 IO 都是同步 IO，一定是刷到磁盘才返回，但是这种使用姿势一般少见，因为这个性能会很差，并且不利于批量优化。
动画演示：
方法二：单独调用函数 fsync
这个则是在 write 之后 fsync 一把数据到磁盘，这种方式实际生产环境用的多些，因为方便业务优化。这种方式对程序员提出了更高的要求，要求必须自己掌握好 fsync 的时机，达到既保证安全又保证性能的目的，这里通常是个权衡点。
比如，你可以 write 10 次之后，最后才调用一把 fsync，这样既能保证刷盘，又达成了批量 IO 的优化目的。
关于这种使用姿势，有几个类似函数，其中有些差异，各自体会下：
// 文件数据和元数据部分都刷盘
int fsync(int fildes);
// 文件数据部分都刷盘
int fdatasync(int fildes);
// 整个内存 cache 都刷磁盘
void sync(void);
动画演示：
这是一个非常有趣的 IO 模式，通过 mmap 函数将硬盘上文件与进程地址空间大小相同的区域映射起来，之后当要访问这段内存中一段数据时，内核会转换为访问该文件的对应位置的数据。从使用姿势上，就跟操作内存一样，但从结果上来看，本质上是文件 IO。
void *
mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset)
int
munmap(void *addr, size_t len);
mmap 这种方式可以减少数据在用户空间和内核空间之间的拷贝操作，当数据大的时候，采用内存映射方式去访问文件会获得比较好的效率（因为可以减少内存拷贝量，并且聚合 IO，数据批量下盘，有效的减少 IO 次数）。
当然，你 write 数据也还是异步落盘的，并没有实时落盘，如果要保证落盘，那么必须要调用 msync ，调用成功，才算持久化落盘。
mmap 的优点：
减少系统调用的次数。只需要 mmap 一次的系统调用，后续的操作都是内存拷贝操作姿势，而不是 write/read 的系统调用； 减少数据拷贝次数；
c 语言示例：
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/stat.h>
#include <assert.h>
#include <fcntl.h>
#include <string.h>
int main()
{
int ret = -1;
int fd = -1;
fd = open("test_mmap.txt", O_CREAT | O_RDWR, 0644);
assert(fd >= 0);
ret = ftruncate(fd, 512);
assert(ret >= 0);
char *const address = (char *)mmap(NULL, 512, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
assert(address != MAP_FAILED);
// 神奇在这里（看起来是内存拷贝，其实是文件 IO）
strcpy(address, "hallo, world");
ret = close(fd);
assert(ret >= 0);
// 落盘确保
ret = msync(address, 512, MS_SYNC);
assert(ret >= 0);
ret = munmap(address, 512);
assert(ret >= 0);
return 0;
}
编译运行看看吧。
gcc -ggdb3 -O0 test_mmap.c -D_GNU_SOURCE
是不是生成了一个 test_mmap.txt 文件，里面有一句 “hello，world”。
动画演示：
硬件缓存
以上方式保证了文件系统那一层的落盘，但是磁盘硬件其实本身也有缓存，这个属于硬件缓存，这层缓存也是易失的。所以最后一点是，为了保证数据的落盘，硬盘缓存也要关掉。
# 查看写缓存状态；
hdparm -W /dev/sda
# 关闭 HDD Cache,保证数据强一致性；避免断电时数据未落盘；
hdparm -W 0 /dev/sda
# 打开 HDD Cache（断电时可能导致丢数据）
hdparm -W 1 /dev/sda
按照内核保证数据落盘，硬件保证关闭缓存，综合以上的 IO 姿势，当你写一笔 IO 落盘之后，才能说数据写到磁盘了，才能保证数据是掉电非易失的。
总结
数据一定要写在非易失性的存储介质里，你才能给用户回复“写成功”。其他的取巧的方式都是耍流氓、走钢丝； 本文总结 3 种最根本的 IO 安全的方式，分别是 O_DIRECT 写，标准 IO + Sync 方式，mmap 写 + msync 方式。要么每次都是同步写盘，要么就是每次写完，再调用 sync 主动刷，才能保证数据安全； O_DIRECT 对使用者提出了苛刻的要求，必须要满足 IO 的 offset，length 扇区对齐，内存 buffer 地址也要扇区对齐； 注意硬盘也有缓存，这个也是易失性的，必须要考虑在内，可以通过 hdparm命令开关；
后记
终于，你可以安心了，数据经过层层险阻来到磁盘了。嘿嘿，你以为数据就安全了吗？里面的名堂还多着呢，磁盘静默错误坏了怎么办？数据还能抢救一下吗？怎么保证网络传输过程不出问题？怎么保证内存拷贝过程不出问题？以后慢慢跟你说；
~完～
往期推荐
往期推荐
坚持思考，方向比努力更重要。关注我：奇伢云存储